+1

What would be the ideal way to use this if you do not want to opt in to a bundled ImmutableJS Nuclear build.

It seems improper to break backwards compatibility if you are already relying on ImmutableJS being bundled.

@raulmatei would you be okay with having to require a sepcific src file or dist file that isn't the package.json main entrypoint?

Starting with npm3 this has actually become a breaking change:

With the introduction of NPM3, peerDependencies behaves differently. It no longer actually installs the peerDependency packages. Instead, it just checks at the end of install to see that they are resolvable, and prints a warning if they are not.
source

As the PR shows, it doesn't require any changes to the code. That however does mean that if you want to avoid a breaking change, you cannot easily solve it by providing a different entry point.

One reason why I think it is a good move is that it would make it easier to include NuclearJS in projects that already depend on ImmutableJS without having to adopt the version that comes with NuclearJS. This for example would also remove the push for NuclearJS to release a new version every time ImmutableJS releases a new version.

What about a major version bump?

@jordangarcia - for time being, having a second build without ImmutableJS would be a way to solve the backwards compatibility issue: import Store from 'nuclearjs/a-good-name-for-the-non-immutable-version', but personally I was looking more after using latest versions of ImmutableJS and not really removing it from NuclearJS bundle, even though I think that the best solution is to keep it outside the bundle because maybe there will be people using an older version and they don't want to upgrade ImmutableJS but want latest features of NuclearJS.

@balloob - yes, I think is a breaking change too and it would probably mean a major version bump as @iansinnott said.

I'll work on getting a major version out this week. I just want to make sure it's natural for people to include ImmutableJS with going through too much trouble.